Virtual queuing techniques

ABSTRACT

The virtual queue system includes a virtual queue controller comprising a processor and a memory, wherein the memory stores instructions executable by the processor and is configured to receive a request, the request being associated with an individual guest, for a position in a virtual queue of an attraction, assign the individual guest to the position in the virtual queue in response to the request, receive ride schedule data for the attraction comprising information about a change in status of individual rides of the attraction, and determine a wait time for the individual guest for the attraction based at least on the position of the individual guest in the virtual queue, the ride schedule data, and historical guest throughput at the attraction. The virtual queue system is further configured to output a signal to a guest-associated device indicating the wait time for the attraction.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority to U.S. Provisional PatentApplication No. 62/419,837, entitled “Systems and Methods forPre-Scheduling In Virtual Queuing Systems,” filed Nov. 9, 2016; and toU.S. Provisional Patent Application No. 62/419,833, entitled “Systemsand Methods for Automatically Monitoring and Dynamically Adjusting AQueue,” filed on Nov. 9, 2016, which are incorporated by reference intheir entireties herein for all purposes.

BACKGROUND

The present disclosure relates generally to the field of amusementparks. Specifically, embodiments of the present disclosure relate totechniques to manage amusement park experiences, including queuing forattractions.

Since the early twentieth century, amusement parks have substantiallygrown in popularity. In order to address this increasing demand,amusement parks have been expanding by adding attractions and space. Theaddition of attractions (e.g., rides, restaurants, shops, and shows)generally provides an amusement park with additional capacity to handlea larger number of guests. However, the additional attractions alsotypically provide potential guests with an incentive to visit theamusement park. Thus, while a particular amusement park may addadditional capacity, the additional capacity does not always result inan increased ability for guests to participate in park entertainment(e.g., shopping, viewing shows, riding rides) or reduced wait times forattractions. This is because there is often a corresponding increase inattendance. Further, due to operating efficiencies, it is oftendesirable to limit the availability of attractions during low attendancetimes. Thus, queuing for attractions, which may limit participation inpark activities, is a perennial issue for amusement parks.

While guests have demanded bigger, better, and more elaborateattractions, they also require and expect a positive overall experience.Providing a positive overall experience for amusement park guestsentails addressing certain issues related to queuing for attractions.Indeed, it is now recognized that park guests can be deterred fromreturning to a particular amusement park due to negative experienceswith queue waiting times. Further, guests may be prevented fromaccessing amusement park businesses (e.g., shops) due to time spentwaiting in queues. Indeed, in the past, guests have waited hours in lineto experience some of the more popular attractions at an amusement park.Additionally, it is now recognized that park capacity does not alwaysresult in efficient guest utilization of that capacity due to individualguest preferences for certain attractions over others. Accordingly, itis now recognized that it is desirable to improve amusement park queuingsystems and methods.

SUMMARY

Certain embodiments commensurate in scope with the originally claimedsubject matter are summarized below. These embodiments are not intendedto limit the scope of the disclosure, but rather these embodiments areintended only to provide a brief summary of certain disclosedembodiments. Indeed, the present disclosure may encompass a variety offorms that may be similar to or different from the embodiments set forthbelow.

In accordance with one embodiment, a virtual queue system is provided.The virtual queue system includes a virtual queue controller comprisingprocessor and a memory. The memory stores instructions executable by theprocessor and is configured to receive a request. The request isassociated with an individual guest and is for a position in a virtualqueue of an attraction comprising a plurality of rides. The virtualqueue permits access of the individual guest to one of the plurality ofrides of the attraction and guests in the virtual queue are distributedbetween the plurality of rides of the attraction via the virtual queue.The memory is further configured to assign the individual guest to theposition in the virtual queue in response to the request, receive rideschedule data for the attraction comprising information about a changein status of individual rides of the plurality of rides, and determine await time for the individual guest for the attraction based at least onthe position of the individual guest in the virtual queue, the rideschedule data, and historical guest throughput at the attraction. Thevirtual queue system further includes communications circuitryconfigured to output a signal to a guest-associated device indicatingthe wait time for the attraction

In accordance with another embodiment, a virtual queue system isprovided. The virtual queue system includes at least one monitoringdevice configured to monitor current queue conditions for an attractionand output a queue condition. The virtual queue system also includes avirtual queue controller comprising a controller and communicationscircuitry. The virtual queue controller is configured to receive thequeue condition signal. The virtual queue controller is also configuredto determine a current wait time for the attraction based on at leastthe queue condition signal and pre-set ride schedule data for theattraction, wherein the pre-set ride schedule data is indicative of aclosure of a subset of a plurality of rides of the attraction. Thevirtual queue controller is further configured to output a queuemodification signal in response to the determined current wait timebeing outside of a predetermined wait time range.

In accordance with another embodiment, a method is provided. The methodincludes the steps of providing ride schedule data for an attractioncomprising a plurality of rides to a virtual queue controller, whereinthe ride schedule data comprises scheduled times associated with closureof a subset of the plurality of rides, calculating variable guestthroughput data for the attraction, wherein the variable guestthroughput data is calculated based at least on current guest throughputdata, the ride schedule data, and historical guest throughput data forthe attraction, determining a current wait time for the next availableposition in a virtual queue for the attraction based on at least thenext available position and the variable guest throughput data, whereinthe current wait time overlaps the scheduled times such that the subsetof the plurality of rides experiences the closure during the currentwait time, and wherein the current wait time is calculated based onfirst variable guest throughput data indicative of a first guestthroughput during the closure and second variable guest throughput dataindicative of a second guest throughput during times outside of theclosure; and outputting a current wait time signal to a display unit, aguest-associated device, or a combination thereof, indicating thecurrent wait time to queue for the attraction.

DRAWINGS

These and other features, aspects, and advantages of the presentdisclosure will become better understood when the following detaileddescription is read with reference to the accompanying drawings in whichlike characters represent like parts throughout the drawings, wherein:

FIG. 1 is a schematic view of a theme park including a virtual queuesystem in accordance with present techniques;

FIG. 2 is a flow diagram of a method using a virtual queue system inaccordance with present techniques;

FIG. 3 is a block diagram of a virtual queue system in accordance withpresent techniques;

FIG. 4 is a block diagram of a virtual queue system including amonitoring device in accordance with present techniques; and

FIG. 5 is a graph showing a wait time range for a virtual queue inaccordance with present techniques.

DETAILED DESCRIPTION

Theme park or amusement park attractions have become increasinglypopular, and various amusement park attractions have been created toprovide passengers with unique motion and visual experiences. Guestsentering the various amusement park attractions may utilize a virtualqueuing system that places the guests in a virtual queue rather than aphysical queue, which allows the guests to enjoy other features of theamusement park while their position in the virtual queue advances. Tohelp guests plan their day, the virtual queuing system may estimate waittimes (e.g., a length of time before the guest may enter the attraction)and provide a reminder to the guest that the time to enter theattraction is approaching. However, in determining wait times for guestsfor each attraction, certain virtual queuing systems assume average waittimes or average guest return rates, or may utilize predetermined orpreconfigured wait times for a static number of rides (e.g.,guest-accepting features of the attraction, such as individual ridevehicles, individual lanes of a multi-lane slide, individual tracks of amulti-track attraction, etc.) within a specific attraction. Using databased on a static number of rides to determine wait times may fail todynamically react to queue conditions (e.g., ride closures and openingsat an attraction). Indeed, such virtual queuing systems may provideinaccurate wait times for guests, which may lead to excessive ordeficient wait times and cause inefficient operation of the amusementpark attractions.

With this in mind, certain embodiments of the present disclosure relateto virtual queuing systems that determine wait times by monitoringand/or dynamically evaluating the virtual queue based at least on queueconditions and scheduling information for the amusement park attraction.Embodiments of the present disclosure facilitate dynamically modifyingqueue operations in response to received feedback associated with thewait times. Specifically, certain embodiments of the present disclosurerelate to determining wait times by monitoring and evaluating dynamicvariations in open/close times for various attractions (or various rideswithin a specific attraction) in addition to queue conditions whendetermining wait times for attractions. In particular, the virtual queuesystem may be configured to utilize scheduled times for each attraction,current or real-time guest throughput for an attraction, estimated guestthroughput in the future, a historical throughput for each attraction,and/or historical queue wait time information to accurately determinewait times for a particular attraction to avoid communicating inaccuratewait times to guests. In this manner, the virtual queuing system mayhelp to prevent ride underutilization, ride overcrowding, and/orinefficient use of ride resources over a period of time. Additionally,certain embodiments of the present disclosure relate to automatically ordynamically modifying queue operations or the actual virtual queue inresponse to deficient or excessive wait times to further preventinefficient operations, ride underutilization, ride overcrowding, and/orwasting ride resources over a period of time. Further, the virtualqueuing system may be configured to monitor and track how the gueststransition or move throughout the queue to provide for a more granularcontrol of the virtual queue. Accordingly, based on a more granularcontrol of the virtual queue, the virtual queuing system may beconfigured to have automatic and dynamic control of attraction access,thereby preventing ride starvation, overcrowding, or wasting other rideresources.

FIG. 1 is a schematic representation of a theme park 110 with at leastone amusement park attraction 112 that may be accessed via a virtualqueue that is controlled by a virtual queue system 114. Certainattractions 112 may feature a plurality of rides 118. For example, inthe depicted embodiment, a water slide attraction 112 a may includemultiple lanes or slides (e.g., shown as rides 118 a, 118 b, and 118 c)that are accessed via a single virtual queue, which permits access to aloading area 116 for the guests. That is, the guests assume a positionin a virtual queue for the attraction 112 a to enter the loading area116. Once in the loading area 116, the guests are distributed betweenseparate slides (i.e., rides 118 a, 118 b, and 118 c) to experience theattraction 112. Accordingly, in the depicted embodiment by way ofexample, the attraction 112 a is capable of accommodating multipleguests (e.g., two, three, or more) at a time. However, the guests mayenter their assigned ride 118 at different rates, leading to dynamicallychanging real-time guest throughput rates for each ride 118 of themulti-ride attraction 112. For example, certain guests may be morehesitant than others, leading to a temporarily slower real-time guestthroughput rate in one ride 118 relative to another. Further, the rideoperators may have different efficiencies in distributing and loadingguests into their respective rides 118. Accordingly, determining a totalguest throughput for a multi-ride attraction 112 may be complex and mayinvolve taking into account different real-time guest throughput ratesat each individual ride 118 of the attraction 112 to determine a totalguest throughput for the attraction 112.

While the depicted embodiments are shown in the context of waterattractions, such as water slides, it should be understood that othermulti-ride attractions 112 are contemplated. Further, the rides 118 ofan individual attraction 112 may include any suitable number of rides118 (slides, tracks, paths vehicles, etc.) accommodating any suitablenumber of guests that are nonetheless accessed via a single virtualqueue for the attraction 112. In addition, the theme park 110 may alsofeature other attractions 112 that do not include multiple rides 118,e.g., single ride attractions 112.

In one embodiment, via the virtual queue system 114, guests are assigneda position in a virtual queue for the amusement park attraction 112after submitting a request from a guest-associated device 120 (e.g.,smart phone, guest wrist band) or a guest kiosk 121 and need notphysically queue to enter the attraction 112 until a designated time.Thus, guests using a virtual queue may spend less time waiting in linesduring their visit to the theme park 110. Additionally, data from thevirtual queue provides guidance to the theme park for scheduling rideopenings and closures to optimize guest throughput and amusement parkattraction efficiency.

In some embodiments, the virtual queue system has a plurality of virtualqueues, each corresponding to a separate amusement park attraction(e.g., 112 a and 112 b). To aid guests in determining which virtualqueue to enter, the virtual queue system 114 is configured to output await time signal 122 indicating current wait times for each amusementpark attraction 112. A display unit 126 may be configured to receive thewait time signal 122 and display the current wait times for guestswithin the theme park 110. The display unit 126 may be a central displayunit configured to display the current wait times corresponding to aplurality of amusement park attractions. However, in some embodiments,the display unit 126 may be a localized display unit configured todisplay a current wait time for a single amusement park attraction. Inanother embodiment, a guest-associated device 120 (e.g., smart phone,guest wrist band, guest tracker, etc.) may receive the wait time signal122 and display the current wait times for a guest (e.g., text message,smart phone app. notification, etc.).

In certain embodiments, the wait time signal 122 transmits the currentwait time, a guest wait time (i.e., a wait time for an individual guestin the virtual queue), or some combination thereof. The current waittime indicates the time that an unqueued guest should anticipate waitingbefore entering the amusement park attraction 112 if joining the virtualqueue at that time. In contrast, the guest wait time indicates the timethat an individual guest, already having a position in the virtualqueue, still has to wait until entering the amusement park attraction112. Thus, the guest wait time corresponds to a specific position of anindividual guest already queued in the virtual queue, whereas thecurrent wait time corresponds to the next available position (i.e., anunassigned position) in the virtual queue.

In an embodiment, the virtual queue system 114 determines wait timesbased at least on scheduling information or ride schedule data for theattraction 112. Ride schedule data includes planned ride openings andclosures for the attractions 112 at specified times during theme parkhours as well as dynamic openings or closures in response to desiredcrowd flow. In the depicted embodiment, the attraction 112 a includesthree rides 118 a, 118 b, and 118 c (e.g., slides, ride vehicles, seats,etc.) accessed by a single virtual queue. One or more of the three rides118 may close during park hours, e.g., at specified times, determined byor included in a ride schedule, for the purpose of increasing attractionefficiency. For example, each of the three rides 118 may have an averagehistorical guest throughput potential of one hundred and twenty guestsper hour. Thus, in the depicted embodiment, a second ride 118 b and athird ride 118 c may close during times of the day when guest throughputis historically low. When guest throughput is low, opening only a firstride 118 a may allow the attraction to maintain sufficient guestthroughput to keep the wait times low while requiring fewer employees tooperate the attraction 112 a. In contrast, when guest throughput ishistorically high, the attraction may open the second ride 118 b and thethird ride 118 c to increase guest throughput in order to minimize thewait times. Because opening and closing rides 118 of the attraction 112dynamically changes real-time guest throughput and future guestthroughput during the closure times, having the virtual queue system 114determine wait times based at least on scheduling information mayprovide more accurate wait times for guests. Thus, schedulinginformation regarding dates, times, and other details as to rideclosures and openings is sent to a virtual queue controller 130 of thevirtual queue system 114. In certain embodiments, scheduling informationis automatically transmitted to the virtual queue controller 130 from atheme park database. In other embodiments, a user may manually enter ormodify scheduling information for the virtual queue controller using anoperator interface 132.

FIG. 2 is a flow diagram of a method 234 of determining the current waittime (e.g., for an as-yet unqueued guest) and the guest wait time forguests in the virtual queue of the attraction 112 using a virtual queuesystem 114 in accordance with present embodiments. The method includesproviding ride schedule data for the attraction 112 to the virtual queuecontroller 114, wherein the ride schedule data includes specified timesfor the one or more rides to open and close (block 236), and whereinopening and closing the one or more rides increases or decreasesestimated guest throughput of the attraction accordingly, calculatingvariable guest throughput data, wherein the variable guest throughputdata is calculated based at least on the ride schedule data andhistorical guest throughput data for the attraction (block 238),determining a current wait time for the next available position in avirtual queue for the attraction 112 based on at least the nextavailable position and the variable guest throughput data (block 240),outputting a wait time signal to a display unit, a guest-associateddevice, or a combination thereof, indicating the current wait time forthe next guest to queue for the attraction 112 (block 242), assigning aguest to a position in a virtual queue for an attraction in response toa guest queue request (block 244), determining a guest wait time for theguest based on at least the position in the virtual queue and thevariable guest throughput data (block 246), and outputting a wait timesignal to the guest-associated device indicating the guest wait time(block 248). Details of the aspects of the method 234 will be discussedin further detail herein with respect to related system features.

In certain embodiments, the method 234 includes the step of furthercalculating the variable throughput data based on current or real-timeguest throughput data. In some embodiments, the method 234 includes thestep of providing queue condition data for the attraction 112 to avirtual queue controller 114, wherein the queue condition data includesat least current guest throughput data for the amusement parkattraction.

In certain embodiments, the virtual queue controller 130 is configuredto continuously or periodically determine the guest wait time and tocontinuously output the wait time signal to the guest-associated device120 indicating an updated guest wait time. In other embodiments, thevirtual queue controller 130 is configured to determine the guest waittime in response to an update request from the guest. The virtual queuecontroller 130 may limit the number of update requests that a guest mayissue. In other embodiments, the virtual queue controller 130 may limitthe rate at which guests may issue update requests. In some embodiments,the virtual queue controller 130 is configured to output the wait timesignal when the virtual queue controller determines that the guest waittime has changed by more than a pre-determined amount of time. Forexample, the virtual queue controller 130 may output a new wait timesignal when the guest wait time has changed by more than two minutes.

FIG. 3 is a block diagram of the virtual queue system 314. The virtualqueue system includes a virtual queue controller 330 (e.g., the virtualqueue controller 130) in communication with the guest-associated device320, the display unit 326, or a combination thereof. To enter thevirtual queue for an attraction 112, the guest-associated device 320transmits a queue request signal 350 to the virtual queue controller 330in response to an input from a guest. The virtual queue controller 330receives the queue request signal 350, determines a wait time for theguest, and outputs a wait time signal 322 to the guest-associated device320, the display unit 326, or a combination thereof. Theguest-associated device 320 and the display unit 326 are configured toreceive the wait time signal 322 and display the wait time for theguest. To enable these communications, the guest-associated device 320,the display unit 326, and the virtual queue controller 330 may includecommunications circuitry 352, such as antennas, radio transceivercircuits, signal processing hardware and/or software (e.g., hardware orsoftware filters, A/D converters, multiplexer amplifiers), or acombination thereof. The communications circuitry 352 may be configuredto communicate over wired or wireless communication paths via IRwireless communication, satellite communication, broadcast radio,microwave radio, Bluetooth, Zigbee, Wifi, UHF, NFC, etc. Suchcommunication may also include intermediate communications devices, suchas radio towers, cell towers, etc.

In certain embodiments, the virtual queue controller 330 may include amemory device 354 a storing instructions executable by a processor 356 ato perform the methods and control actions described herein. Forexample, the processor 356 a may execute instructions for dynamicallyevaluating virtual queue conditions and determining wait times forguests based on guest throughput inputs 358 and ride schedule datainputs 360 received by the virtual queue controller 330. The rideschedule data inputs may be received through user input, from a memorystorage, and/or through cloud services. The virtual queue controller 330may receive scheduling (or re-scheduling) information in real-time, andmay be configured to update wait times based on the updated schedule. Incertain embodiments, the virtual queue controller 330 may receive andutilize additional inputs in combination with the ride schedule datainputs 360 and guest throughput inputs 358 when determining wait times.

Further, in certain embodiments, the processor 356 a may utilizehistorical queue condition data inputs 362 (e.g., historical weatherinformation, previous guest behavior within a particularride/attraction, calendar information (e.g., time of day, day of week,holidays, etc.), demographic information, number of guests within agroup(s), and so forth) in combination with the ride schedule datainputs 360 and/or guest throughput inputs 358 when determining waittimes. For example, the processor 356 a may account for historicallyslower crowds or colder seasons conditions when providing wait times. Asa further example, in certain embodiments, the processor 356 a mayutilize various characteristics of the guests (e.g., type, gender, age,number, etc.) within the queue, in combination with the ride scheduledata inputs 360 and guest throughput inputs 358, in order to determinewait times. While the guest throughput inputs 358, ride schedule datainputs 360, and historical queue condition data inputs 362 are depictedas being received via an operator interface 332, it should be understoodthat the various inputs to the virtual queue controller 330 may bereceived from other components of the system 314. In one embodiment, theguest throughput inputs 358 comprise real-time throughput informationthat is transmitted to the virtual queue controller 330 based onguest-associated device 320 interaction with a check-in or tap-in deviceor by passing through a gate at each attraction 112. For example, aseach guest enters the attraction 112, the associated guestidentification information from the guest-associated device 320 is readby a reader comprising communication circuitry and associated with theattraction. In an embodiment, each individual ride 118 of the attraction112 is configured to provide guest identification from a readerpositioned at a top or start of each ride 118. The guest identificationinformation, associated attraction 112 information and/or ride 118information, and timestamp may be provided to the virtual queuecontroller 330 as inputs to determine dynamic real-time guest throughput(e.g., guests/hour). Further, the attraction 112 may also include areader at a ride exit to track total time through the ride 118 as avariable in determining real-time guest throughput. In anotherembodiment, the real-time guest throughput may be based on operatorinformation. For example, a ride operator may track a number of guestsand provide guest numbers periodically to the operator interface 332.Further, the virtual queue controller 330 may store the guest throughputinformation to update historical queue condition inputs 362 usingacquired guest throughput data.

The processor 356 a of the virtual queue controller 330 may include oneor more processing devices, and the memory may include one or moretangible, non-transitory, machine-readable media. By way of example,such machine-readable media can include RAM, ROM, EPROM, EEPROM, oroptical disk storage, magnetic disk storage or other magnetic storagedevices, or any other medium which can be used to carry or store desiredprogram code in the form of machine-executable instructions or datastructures and which can be accessed by the processor or by otherprocessor-based devices (e.g., mobile devices). For example, the virtualqueue controller 330 may be accessed by an operator interface 332 (e.g.,a computer-based workstation or a mobile device, and/or may include aninput/output interface 364 and a display).

In certain embodiments, the guest-associated device 320, having aprocessor 356 b and a memory 354 b, may be a personal guest device(e.g., smart phone, tablet, laptop, etc.) or a park queue deviceassigned to guests (e.g., smart wrist bands, portable communicationdevices, etc.). Park queue devices include a program for viewing waittimes and sending queue requests. Guests using personal guest devicesmay be given access to the program (e.g., web based program, smart phoneapp., downloadable program, etc.). For example, an admission ticket tothe theme park or a confirmation email may include details for findingthe program, as well as a username, a passcode, or a combinationthereof, for accessing the program. Personal information associated witha guest (height, weight, age, and other demographics) may be linked tothe username and/or passcode, such that the guest identificationinformation may be transmitted with the queue request signal. A guestusing park queue devices may have their guest information uploaded tothe park queue device when the device is assigned to the guest. Thevirtual queue controller 330 may utilize guest identificationinformation determining wait times as provided herein.

In certain embodiments, the system may include a queue station (e.g.,guest kiosk 121) that includes a processor and a memory, and isconfigured to provide an additional resource for guests to view timesand send queue requests. Guests may access queuing functionality on thequeue station using a form of guest identification (e.g., username,passcode, card, RF wristband, personal information, etc.). Queuestations may be disposed at various locations around the theme park 110.In some embodiments, at least one queue station is disposed proximate anentrance of each attraction 112, such that guests are provided a meansto queue for the attraction 112 at a location proximate the attraction112. In some embodiments, queue stations may only permit guests to queuefor the attraction 112 most proximate the queue station. In otherembodiments, general queue stations are located throughout the themepark 110, which may be used to queue for attractions 112 in the themepark 110.

In certain embodiments, the display unit 326 is configured to receivethe wait time signal 322 from the virtual queue controller 330 anddisplay current wait times for the attractions 112. In some embodiments,at least one display unit 326 is disposed proximate an entrance of eachattraction 112. The display unit may be configured to display only thecurrent wait time for the attraction 112 most proximate the displayunit. In other embodiments, general display units are disposed ingeneral locations (e.g., eating areas, walking paths, etc.) around thetheme park 110. General display units may display current wait times fora plurality of attractions 112.

FIG. 4 is a block diagram of the virtual queue system 414 having amonitoring device 466. In the present embodiment, the monitoring device466 may have communication circuitry 452 d to establish communicationwith the virtual queue controller 430. The monitoring device 466 mayalso have a processor 456 c and a memory device 454 c. The monitoringdevice 466 is configured to monitor and/or determine current queueconditions and output a queue condition signal 468 to the virtual queuecontroller 430. In some embodiments, the attraction 112 has both aphysical queue and a virtual queue. In such embodiments, a guest firstenters a virtual queue before entering the physical queue. The physicalqueue provides a buffer queue or a standby area for the attraction 112to increase efficiency of the attraction 112. For example, in the eventthat a guest does not arrive to the attraction 112 at the timedesignated by the virtual queue system 414, without a physical bufferqueue, it is possible that no guest would be present to fill theposition of the absent guest. Therefore, at least one ride 118 of theattraction 112 may proceed with less than maximum occupancy of the ride,thereby, decreasing efficiency of the attraction 112. However, usingboth a physical queue and a standby area, a plurality of guests may bepresent at the attraction 112 to fill the ride to max occupancy, evenwhen a guest does not arrive on time. In certain embodiments, themonitoring device 466 is configured to monitor current queue conditionsof the physical queue. However, the monitoring device 466 may beconfigured to monitor current queue conditions of the physical queue,the virtual queue, or a combination thereof. Further, in certainembodiments, the attraction 112 may be implemented without a physicalqueue.

In certain embodiments, the monitoring device 466 may be configured tomonitor or determine current queue conditions, including, but notlimited to, the length of the queue, number of guests in the queue, flowrate of the guests entering and exiting the queue, particularindividuals within the queue (e.g., identify guests in the queue),number of sub-queues within the queue, types of guests within the queue,and so forth. In certain embodiments, the monitoring device 466 maymonitor particular locations (e.g., geographical location, queue zones,etc.) within the queue and output the number of guests in eachparticular location to the virtual queue controller. In certainembodiments, the monitoring device 466 may monitor guests not just atthe beginning or end of the queue, but may also monitor whether guestsleave the queue in the middle of the queue. In certain embodiments, themonitoring device 466 may determine various characteristics of theguests (e.g., type, gender, age, number, etc.) within the queue andoutput that data to the virtual queue controller 430 to track and recordhistorical throughput data associated with the queue as it relates tothe attraction 112.

In certain embodiments, the monitoring device 466 includes a countingmechanism 470 configured to monitor queue conditions. For example, thenumber of guests within the queue may be monitored with a countingmechanism 470, which may be a manual system and/or may include one ormore sensors disposed proximate to the queue. In other embodiments, themonitoring device may include at least one sensor 472 (e.g., opticalsensors, mechanical treadles, RF sensing systems, etc.) disposedphysically proximate to the queue, and communicatively coupled to thevirtual queue controller 430. The sensors 472 may provide continuousfeedback to the virtual queue system 414 associated with current queueconditions. For example, in situations where guests each carry RFidentification, RF sensors associated with the monitoring device may beconfigured to monitor when the particular guest(s) enters and exits thequeue and output that data to the virtual controller. As a furtherexample, the sensors 472 may be configured to recognize individualguests at the entrance and exit of the queue and continuously outputthat information to the virtual queue controller, such that variousconditions of the queue (e.g., wait time, queue length, etc.) may becalculated based on length of time individual guests spend within thequeue.

Based on the received feedback, the virtual queue system 414 may beconfigured to dynamically respond to current queue conditions. Incertain embodiments, the virtual queue system 414 may include thefunctionality to automatically remove a guest from the virtual queuebased on one or more factors (e.g., been in the queue for an extendedperiod of time past current queue wait time, guest is seen at anunexpected location within the queue, guest enters another queue, guestis recognized outside of the queue, etc.). In certain embodiments, thevirtual queue system 414 may virtually monitor and dynamically adjust aplurality of queues (or sub-queues), and may be configured to correlatethe data for a variety of queues when calculating or determining currentqueue conditions.

In certain embodiments, the virtual queue system 414 may utilize thefeedback received from the monitoring device 466 to calculate otherqueue conditions. The virtual queue system 414 may calculate variousfactors or variables, such as, but not limited to, length of the virtualqueue, current or real-time guest throughput, maximum attractionthroughput, historical information related to queue conditions andresponses (e.g., historical guest throughput), length of time that thequeue is in different states (overfill state, under-fill state,starvation state, overcrowding state, etc.), and so forth. For example,based on the number of guests within the queue and/or the flow rate ofthe guests entering or exiting the queue, the virtual queue system 414may calculate current wait times, guest wait times, current attractioncapacity, and so forth. In particular, the virtual queue system 414 maybe configured to determine accurate real-time information related to thequeue system and queue conditions, based at least in part on thecontinuous feedback received from the monitoring device 466.

In another embodiment, in response to determined wait times for guestsin the virtual queues and/or physical attraction access areas, thevirtual queue system 414 may be configured to output a queuemodification signal 474. Specifically, the virtual queue system may beconfigured to dynamically respond to deviations of the calculated waittimes for guests from a wait time range by outputting a queuemodification signal 474.

In certain embodiments, the queue modification signal 474 is configuredto temporarily disable the ability to add a guest to the virtual queuefor an attraction 112 when the wait time for the attraction is longerthan a maximum limit of the wait time range. For example, when thevirtual queue is deemed too long by the virtual queue controller 430,the virtual queue controller is configured to output the queuemodification signal 474 to the guest-associated device 420 (e.g. smartphone, guest kiosk, etc.). The queue modification signal 474 isconfigured to transmit instructions to a queue program, on theguest-associated device 420, to disable an option to send a queuerequest for the attraction 112. Additionally, the queue modificationsignal 474 may include instructions to display a message in relation todisabling a portion of the queue program. Once wait times of the virtualqueue fall back down to a length of time within the wait time range, thevirtual queue controller 430 may be configured to send a resume signal476 to enable the option to send queue requests.

In certain embodiments, the queue modification signal 474 includesinstructions to notify guests of a shorter than average queue time foran attraction 112 when the wait time for the attraction is shorter thanthe minimum limit of the wait time range. For example, the queuemodification signal 474 may include instructions for theguest-associated device to display a message indicating that theattraction 112 has a short wait time. In some embodiments, the queuemodification signal 474 may include instructions to activate a quickqueue option in the program on the guest-associated device 120. Forexample, the quick queue option may activate a pop up message the screenthat indicates that the virtual queue has a short wait time.Additionally, the pop up message may include a button configured toimmediately enter the guest into the virtual queue for the attraction112. In certain embodiments, the virtual queue controller 430 isconfigured to send the queue modification signal 474 to guest-associateddevices 420 linked to guests that have experienced fewer attractions 112during that day than other guests at the theme park 110 before sendingthe queue modification signal to the other guests, thereby giving afirst opportunity to enter the virtual queue to individuals who haveexperienced fewer attractions 112. In certain embodiments, the programincludes an option to dismiss messages activated in response to theguest-associated device receiving the queue modification signal 474.However, once wait times of the virtual queue rise up to a length oftime within the wait time range, the virtual queue controller isconfigured to send the resume signal to automatically dismissnotifications from the queue modification signal.

In certain embodiments, the virtual queue controller is configured tosend an attraction modification signal 478 to an amusement park operatordevice 480 in response to the wait times longer than the maximum limitor shorter than the minimum limit of the wait time range. The attractionmodification signal is configured to send instructions to an amusementpark operator to open and/or close rides of an amusement park ride 118to adjust current guest throughput in response to the wait times. Inaddition to disabling the virtual queue or sending notifications,dynamically opening and closing rides 118 of an attraction 112 mayfurther increase amusement park attraction efficiency.

FIG. 5 is a graph showing the wait times 582 and a wait time range 584for the virtual queue. The wait time range provides a minimum wait time586 and a maximum wait time 588 for acceptable wait times at particulartimes, e.g., whereby wait times between the minimum wait time 586 andthe maximum wait time 588 may bound a predetermined desired wait timerange. When wait times 582 as calculated or estimated by the virtualqueue controller (e.g., virtual queue controller 430) as provided hereinfall below the minimum wait time 586 or rise above the maximum wait time588, the virtual queue controller 430 is configured to output the queuemodification signal 474. In certain embodiments, the virtual queuecontroller 430 calculates the wait time range 584 based at least onhistorical throughput data. The virtual queue controller 430 maydetermine an average wait time 590 for an attraction 112 for each timeslot of a day using the historical throughput data. The virtual queuecontroller 430 may determine a plurality of average wait times, whereinan average wait time is calculated for each time slot of each day of aweek, month, year, etc. For example, the virtual queue controller 430may calculate an average wait time for an attraction 112 at 10 a.m. byaveraging all historical throughput data for the time slot of 10 a.m.However, in other embodiments, the virtual queue controller 430calculates an average wait time for Monday at 10 a.m. by averaging allhistorical throughput data for every Monday at 10 a.m. Additionally oralternatively, the virtual queue controller 430 may further utilizehistorical queue condition data (e.g., historical ride schedule data,historical guest throughput, weather data, guest behavior, calendarinformation, demographic info, number of groups of guests, size ofgroups of guests, etc.) in determining the plurality of average waittimes 590.

In certain embodiments, the virtual queue controller 430 may calculatethe wait time range 584 by adding a wait time buffer to the average waittime 590. For example, the virtual queue controller 430 may calculateaverage wait times for 9 a.m., 11 a.m., 1 p.m., and 3 p.m. to be five,twenty, forty, and thirty-five minutes respectively. The virtual queuecontroller 430 may provide a five minute wait time buffer to the averagewait times to calculate the wait time range. Thus, the wait time rangesat 9 a.m., 11 a.m., 1 p.m., and 3 p.m. are 0-10 minutes, 15-25 minutes,35-45 minutes, and 30-40 minutes respectively. In other embodiments, thevirtual queue controller 430 may calculate the wait time range 584 usinga dynamic wait time buffer. The dynamic wait time buffer may change alength of time of the wait time buffer at different time slots of a day.For example, a wait time buffer at 9 a.m. may be five minutes, while await time buffer at 1 p.m. may be fifteen minutes. In other embodiments,the dynamic wait time buffer includes a longer wait time buffer betweenthe average wait time and the maximum limit than the wait time bufferbetween the average wait time and the minimum limit. In someembodiments, the dynamic wait time buffer may be determined usinghistorical throughput data, operator input, etc.

In certain embodiments, the wait time range may be set based on inputsreceive by the virtual queue controller 430. In some embodiments, thevirtual queue controller 430 is configured to receive an input from theoperator interface 332. An operator may transmit instructions for thevirtual queue controller 430 to set specific wait time ranges using theoperator interface 332. The operator may set static or dynamic wait timeranges. In some embodiments, an operator may set a wait time rangeindependent of historical throughput data. For example, in the eventthat an attraction 112 is temporarily under staffed, an operator mayadjust the wait time range 584 of the attraction 112 to decrease guestthroughput of the attraction 112 until the attraction 112 is properlystaffed. In another example the operator may adjust the wait time ranges584 for a plurality of attractions 112 to encourage guests to queue forthe particular attraction 112, in order to prevent overcrowding of otherattractions 112 or locations.

In certain embodiments, the virtual queue controller 430 may determinewait times 582 for a position in the virtual queue based on variableguest throughput data and ride schedule data. Generally, the virtualqueue controller 430 calculates a variable guest throughput based atleast on current guest throughput data, historical throughput data,historical ride schedule data, etc. The variable guest throughput datarepresents an expected guest throughput for a single ride 118 of theattraction 112 for each time slot during park hours. The virtual queuecontroller 430 is configured to predict expected guest throughput dataat least based on deviations of current guest throughput data withrespect to historical throughput data and other queue conditions. Toaccurately analyze throughput variations and prevent schedulingvariations from skewing the calculation, the current guest throughputdata and the historical throughput data are first divided respectfullyby the number of rides currently open and the number of rideshistorically open (i.e., to determine current guest throughput data andhistorical guest throughput data for a single ride). Further, thevirtual queue controller 430 is configured to dynamically multiply theexpected guest throughput data for a single ride according to the rideschedule data to determine an expected guest throughput for each timeslot during the park hours. The virtual queue controller 430 isconfigured to utilize the expected guest throughput, current queueconditions (e.g., number of guests in queue, etc.) in relation to theguest position to determine wait times.

As an exemplary embodiment, in certain situations, an attraction 112 mayinclude one or more rides 118 that open and close at different timesthroughout the day. For example, a first ride 118 a of an attraction 112may open concurrently with the opening of theme park 110, and a secondride of the attraction 112 may open an hour after the theme park 110opens. Each ride of the attraction 112 may have a throughput of 120guests per hour. Features of the present disclosure enable the virtualqueuing system to utilize the scheduled open/close times of each rideduring the day to determine wait times for the attraction 112. Forexample, the virtual queuing system accounts for the delayed openingtime of the second ride 118 b when determining a wait time for theattraction 112. In this manner, the virtual queuing system may providean accurate wait time for the attraction 112, rather than anartificially low wait time that would be associated with the cases ofall rides 118 being open. In other words, when one or more of the rides118 are closed, the estimated total guest throughput of the attraction112 will be reduced. Further, the virtual queuing system 114 accountsfor the one hour delay in opening the second ride 118 b during waittimes assigned before the second ride 118 b is scheduled to open.

For example, in an embodiment, a guest requests a position in thevirtual queue such that the guest wait time for the attraction 112encompasses or overlaps a first time period in which a subset of therides 118 are closed and a second time period in which all of the rides118 are open. That is, some or all of the closed rides 118 are openedwhile the guest is in the virtual queue. Accordingly, the attraction 112has an estimated lower guest throughput during the first time period andan estimated higher guest throughput during the second time period. Byusing the lower guest throughput and the higher guest throughput, a moreaccurate guest waiting time may be determined. In this manner, thevirtual queuing system may avoid periods of ride starvation (whenartificially high wait times are reported), or ride overcrowding (whenartificially low wait times are reported).

In one embodiment, for the attraction 112, historical guest throughputdata may show that, on average at 1 p.m., the attraction 112 has a guestthroughput of 240 guests per hour and a guest throughput at 2:00 p.m. of220 guests per hour, both with two rides open. The current conditions,as determined by the monitoring device 466, indicate that the currentguest throughput of the ride at 1 p.m. is 120 guests per hour with oneride 118 a open. However, ride schedule data provided to the virtualqueue controller 430 indicate that a second ride 118 b is scheduled toopen at 1:30 p.m. First, the virtual queue controller may determine thatthe historical guest throughput for one ride vehicle at 1:00 p.m. is 120guests per hour, and that the ride throughput per vehicle is on par withhistorical guest throughput data. However, the historical guestthroughput data shows a trend indicating that at 2:00 p.m., guestthroughput for one ride vehicle historically decreases to 110 guests perhour. The virtual queue controller 430 may be configured to consider thedecreasing guest throughput in calculating wait times. Additionally,although the current guest throughput is only 120 guests per hour, thevirtual queue controller is configured to increase the expected guestthroughput by a factor of two at 1:30 p.m. to account for the opening ofthe second ride vehicle. The expected ride throughput should increase to240 guests per hour minus the anticipated decrease in guest throughput.Thus, the expected ride throughput at 1:30 p.m. may be 230 guests perhour. Using the estimated guest throughput data and current queueconditions in relation to the guest position, the virtual queuecontroller may dynamically determine wait times 582. Additionally, incertain embodiments, the virtual queue controller may continuallycalculate the variable guest throughput to account for changes incurrent guest throughput and other queue conditions, in order to provideguests with updated wait times.

In some embodiments, the virtual queue controller 430 further utilizesother queue conditions to determine wait times 582. Specifically, thevirtual queue controller 430 may be configured to consider variousfactors, such as, but not limited to, previous guest behavior, guests'current activities within and outside of the queue, current location orhistorical locations of the guest within the park, weather, calendarinformation (e.g., time of day, day of week, holidays, etc.),demographic information, number of guests within a group(s), and soforth. Further, in certain embodiments, the virtual queue controller 430may record real-time queue conditions as historical queue conditioninformation for future use. For example, acquired real-time queueconditions may indicate that one ride 118 a has historically slowerguest throughput relative to the other rides 118 b, 118 c, even if allthree rides 118 are otherwise alike or of a same type. Such slowerthroughput may be because an entrance in the loading area for the ride118 a is farther from the entrances of the other rides 118 b, 118 c,because a loading angle involves slower loading, or because show propsadjacent the ride 118 a cause guests to linger at the ride entrance.Accordingly, a more accurate estimated guest wait time may take intoaccount which of the rides 118 is closed and use historical guestthroughput information associated with each individual ride 118. Forexample, when the slower ride 118 a is closed, the estimated guest waittime may use historical guest throughput for the faster rides 118 b, 118c and not from the closed slower ride 118 a in calculating an estimatedguest wait time.

In certain embodiments, the virtual queue controller 430 may beconfigured to determine the wait times 582 for each attraction 112 basedon a coordinated analysis of other queue conditions. For example, incertain embodiments, the virtual queue controller 430 may receive rideschedule data and guest throughput data for a plurality of attractions112, and may be configured to coordinate the wait times 582 for theattractions 112 based on the received data. In certain embodiments, thevirtual queue controller 430 may utilize other types of data to performa coordination analysis. For example, the virtual queue controller mayreceive crowd flow data and/or wait times for other rides, and mayutilize this data to provide accurate wait times 582 for each attraction112.

While only certain features of the present disclosure have beenillustrated and described herein, many modifications and changes willoccur to those skilled in the art. It is, therefore, to be understoodthat the appended claims are intended to cover all such modificationsand changes as fall within the true spirit of the disclosure.

The techniques presented and claimed herein are referenced and appliedto material objects and concrete examples of a practical nature thatdemonstrably improve the present technical field and, as such, are notabstract, intangible or purely theoretical. Further, if any claimsappended to the end of this specification contain one or more elementsdesignated as “means for [perform]ing [a function] . . . ” or “step for[perform]ing [a function] . . . ”, it is intended that such elements areto be interpreted under 35 U.S.C. 112(f). However, for any claimscontaining elements designated in any other manner, it is intended thatsuch elements are not to be interpreted under 35 U.S.C. 112(f).

1. A virtual queue system, comprising: a virtual queue controllercomprising a processor and a memory, wherein the memory storesinstructions executable by the processor and is configured to cause thevirtual queue controller to: receive a request, the request beingassociated with an individual guest, for a position in a virtual queueof an attraction, the attraction comprising a plurality of rides,wherein the virtual queue permits access of the individual guest to oneof the plurality of rides of the attraction, and wherein guests in thevirtual queue are distributed between the plurality of rides of theattraction via the virtual queue; assign the individual guest to theposition in the virtual queue of the attraction in response to therequest; receive ride schedule data for the attraction, wherein the rideschedule data comprises information about a change in status ofindividual rides of the plurality of rides; and determine a wait timefor the individual guest for the attraction based at least on theposition of the individual guest in the virtual queue, the ride scheduledata, and historical guest throughput at the attraction; andcommunications circuitry configured to output a signal to aguest-associated device indicating the wait time for the attraction. 2.The system of claim 1, further comprising at least one monitoring devicedisposed at the attraction, wherein the at least one monitoring deviceis configured to generate a guest throughput signal indicative ofreal-time guest throughput for the attraction and output the guestthroughput signal.
 3. The system of claim 2, wherein the virtual queuecontroller is configured to receive the guest throughput signal from theat least one monitoring device.
 4. The system of claim 2, wherein the atleast one monitoring device comprises at least one sensor and whereinthe virtual queue controller is configured to receive one or moresignals from the at least one sensor indicative of a number of theguests entering the attraction, a number of the guests exiting theattraction, a flow rate of the guests entering the attraction,identities of the guests entering the attraction, or some combinationthereof.
 5. The system of claim 1, wherein the virtual queue controlleris further configured to determine a next available wait time for theattraction based at least on a next available position of the virtualqueue.
 6. The system of claim 5, wherein the virtual queue controller isconfigured to output a queue modification signal when the next availablewait time deviates from a historic wait time by more than a set amount.7. The system of claim 1, wherein the virtual queue controller isconfigured to dynamically update the wait time for the individual guestand output an updated wait time signal to the guest-associated devicebased on receiving a change in the ride schedule data.
 8. The system ofclaim 1, wherein the plurality of rides of the attraction are accessedvia a single loading area of the attraction.
 9. The system of claim 8,wherein access to the single loading area is based on the position ofthe individual guest in the virtual queue.
 10. The system of claim 1,wherein the plurality of rides of the attraction are of a same type. 11.The system of claim 1, wherein the ride schedule data is indicative of aclosure of a subset of the individual rides over a time range.
 12. Thesystem of claim 11, wherein the determined wait time during the timerange is longer relative to later times when the subset of theindividual rides are open.
 13. The system of claim 11, wherein the rideschedule data is indicative of the closure of the subset at the time ofthe request and a subsequent opening of the subset during the wait time,wherein the wait time is determined based on an increase in estimatedguest throughput for the attraction for a portion of the wait time afterthe opening.
 14. The system of claim 11, wherein the ride schedule datais indicative of the closure of the subset after receiving the request,wherein the wait time is determined based on a decrease in estimatedguest throughput for the attraction for a portion of the wait time afterthe closure.
 15. A virtual queue system, comprising: at least onemonitoring device configured to monitor current queue conditions for anattraction and output a queue condition signal; and a virtual queuecontroller comprising a controller and communications circuitry, whereinthe virtual queue controller is configured to: receive the queuecondition signal; determine a current wait time for the attraction basedon at least the queue condition signal and pre-set ride schedule datafor the attraction, wherein the pre-set ride schedule data is indicativeof a closure of a subset of a plurality of rides of the attraction; andoutput a queue modification signal in response to the determined currentwait time being outside of a predetermined wait time range.
 16. Thesystem of claim 15, wherein the queue modification signal is configuredto temporarily disable an ability to add a guest to a virtual queue forthe attraction when the current wait time is above a maximum wait timeof the wait time range.
 17. The system of claim 16, further comprising aguest kiosk configured to receive the queue modification signal anddisable a user input in response to receiving the queue modificationsignal, wherein the guest kiosk is configured to transmit a request fora position in the virtual queue of the attraction based on the userinput.
 18. The system of claim 16, wherein the virtual queue controlleris configured to output the queue modification signal to aguest-associated device to cause the guest-associated device to disablea user input, wherein the guest-associated device is configured totransmit a request for a position in the virtual queue of the attractionbased on the user input.
 19. A method, comprising: providing rideschedule data for an attraction comprising a plurality of rides to avirtual queue controller, wherein the ride schedule data comprisesscheduled times associated with closure of a subset of the plurality ofrides; calculating variable guest throughput data for the attraction,wherein the variable guest throughput data is calculated based at leaston current guest throughput data, the ride schedule data, and historicalguest throughput data for the attraction; determining a current waittime for a next available position in a virtual queue for the attractionbased on at least the next available position and the variable guestthroughput data, wherein the current wait time overlaps the scheduledtimes such that the subset of the plurality of rides experiences theclosure during the current wait time, and wherein the current wait timeis calculated based on first variable guest throughput data indicativeof a first guest throughput during the closure and second variable guestthroughput data indicative of a second guest throughput during timesoutside of the closure; and outputting a current wait time signal to adisplay unit, a guest-associated device, or a combination thereof,indicating the current wait time to queue for the attraction.
 20. Themethod of claim 19, wherein the historical throughput data compriseshistorical guest throughput data for the one or more attractions inrelation to a number of rides open, weather data, guest behavior,calendar information, demographic info, number of guests in a group,size of groups of guests, or some combination thereof.
 21. The method ofclaim 19, further comprising updating the ride schedule data signal whenthe ride schedule data is changed.